19.6 Troubleshooting MyID Client Service connection issues

This section contains information about problems you may experience when using the MyID Client Service to connect to MyID Desktop or the Self-Service App.

19.6.1 Connection issues

If you attempt to use a feature of the MyID Operator Client and get an error similar to:

OC10009 – Unable to connect to MyID Desktop or the Self-Service App. Please try again.

This means there has been a problem with the connection between the MyID Client Service and MyID Desktop or the Self-Service App that caused the operation to exceed the timeout period. By default, this is 60 seconds; for information on configuring the timeout, see section 19.4.13, Configuring the timeout for launching external applications.

The possible causes are:

• The application could not start.

• The application took a long time to start.

• The application is already running, but not responding.

The troubleshooting procedure for this issue is:

1. Check the MyID Client Service log:

   1. Right-click the MyID Client Service icon in the Windows system tray.

   2. From the pop-up menu, click Show.

      The MyID Client Service window appears.

      

   3. Check the log output for any messages relating to starting MyID Desktop (DSK) or the Self-Service App (SSA).

      If the problem is not apparent, continue with the troubleshooting.

2. Check whether the problem is a slow startup:

   1. Wait a few seconds before trying the operation again.

   2. If the operation succeeds after giving it sufficient time, check the following:

      • Network conditions

      • Client hardware requirements

      • Internet access

      If there is no Internet access, you may experience slow startup due to signature checks and CRL verification; in this case you can try one of the following:

      • Disable the signature checks. See section 19.4.11, Signature validation.

      • Increase the timeout. See section 19.4.13, Configuring the timeout for launching external applications.

   If this does not resolve the problem, continue with the troubleshooting.

3. Check if MyID Desktop or the Self-Service App are already running, and can be started:

   1. Close all open MyID Desktop or Self-Service App windows.

   2. Open the Windows Task Manager, then on the Details tab verify that no MyIDDesktop or MyIDApp processes are running.

      

      If there are processes running, use the Task Manager to close them; select the process and click End Task.

   3. Keeping the Task Manager open, try the operation again in the MyID Operator Client.

   4. If you do not see the MyIDDesktop or MyIDApp process appear in the Task Manager before the OC10009 error, this means that the application cannot start.

      Try launching MyID Desktop or the Self-Service App from the Windows Start menu; if this does not work, there is a problem with your installation of the application. Uninstall and then re-install your clients, then try again.

      If the issue persists after a reinstall, check any .NET errors relating to MyIDDesktop or MyIDApp in the Windows Event Viewer under Windows Logs > Application.

      Make sure you have the correct version of the .NET Core Desktop Runtime; see the Additional hardware and software requirements section in the Installation and Configuration Guide.

   5. If you do see the MyIDDesktop or MyIDApp process appear in the Task Manager before the OC10009 error, try the operation again.

4. If you are still unable to launch MyID Desktop or the Self-Service App from the MyID Operator Client:

   1. Set up logging for the appropriate applications.

      See the Windows clients section in the Configuring Logging guide.

   2. Try the operation again to ensure that the relevant information is included in these logs.

   3. Send the logs to Intercede Customer Support quoting reference SUP-364.

19.6.3 Server name does not resolve

If, when you log on to the MyID Operator Client, the logon pop-up completes in a manner normal to a successful logon, but the MyID Operator Client does not log in, the rest.core web service is not working successfully.

The possible causes are:

• Issues with load balancing.

• The rest.core web service cannot resolve the server name URL.

To troubleshoot this issue, first ensure that you are load balancing correctly. For more information on load balancing, see section 19.4.6, Load balancing.

If you are correctly load balancing, it is likely that the rest.core web service cannot connect to the following URL:

https://<servername>/web.oauth2/.well-known/openid-configuration

Where <servername> is the name of your server.

To check, set the logging for rest.core to ALL. Fore more information on logging for rest.core, see the MyID REST and authentication web services section of the Configuring Logging guide.

If the issue is that rest.core cannot resolve the URL, you will likely see the following error message.

Bearer was not authenticated. Failure message: IDX10204: Unable to validate issuer. validationParameters.ValidIssuer is null or whitespace AND validationParameters.ValidIssuers is null or empty.

You can narrow down the causes of the issue by carrying out the following procedure:

1. Log in to the web server with the MyID web service user account.

   This is the user account under which the rest.core service runs.

2. Run one of the following commands:

   • In PowerShell, run:

     Invoke-WebRequest https://<servername>/web.oauth2/.well-known/openid-configuration

   • At the Windows command prompt, run:

     curl https://<servername>/web.oauth2/.well-known/openid-configuration

   Where <servername> is the name of your server.

If you do not receive valid JSON as a response to your command, the issue is that the web service user on the web server cannot resolve the server URL. Possible causes include:

• A firewall is preventing the https call from being made.

  Check both the Windows Firewall and any external firewalls. If they are preventing the https call from being made, adjust the firewall rules.

• The server host name is not resolvable.

  You can check this by pinging the web server from the web service user account.

  At the Windows command prompt, run:

  ping <servername>

  Where <servername> is the name of your server.

  If this does not resolve to the expected IP address, the DNS lookup is not working. If necessary, you can use the hosts file on the web server to ensure that the web server's address resolves to its own IP address.

• The web server is not available on the server. To check if this is the issue, and why this is the issue, run one of the following commands:

  • In PowerShell, run:

    Invoke-WebRequest https://<servername>

  • At the Windows command prompt, run:

    curl https://<servername>

  Where <servername> is the name of your server.

  If the https URL cannot be reached, there is no connectivity to IIS over https.

  Then, run one of the following commands:

  • In PowerShell, run:

    Invoke-WebRequest http://<servername>

  • At the Windows command prompt, run:

    curl http://<servername>

  Where <servername> is the name of your server.

  If you can reach the http URL, but cannot reach the https URL cannot, there is probably an issue with TLS.

• The web server TLS certificate is invalid or not trusted.

  You can check if this is the issue by opening an Edge browser and entering the following URL:

  https://<servername>/web.oauth2/.well-known/openid-configuration

  Where <servername> is the name of your server.

  If there are TLS issues, the Edge browser can help you identify the issue. Some possible issues are:

  • The root CA is not trusted.

    The root CA must be in the Trusted Root Certificate Authority certificate store when viewed on the web server by the web service user account.

  • Intermediate CAs are not known.

    If the intermediate CAs are not known, the Certificate Hierarchy may look incomplete. The Certificate Hierarchy is available on the Details page of the Certificate Viewer in the Edge browser.

    The intermediate CAs either must be resolvable from the URLs in the AIA extension, or must already be in the Intermediate Certificate Authority certificate store when viewed on the web server by the web service user account.

  • The origin in the TLS certificate does not match the origin in the URL of the https request.

    The origin in the TLS certificate is stored as the DNSName.

  • Your https inspection proxy is switching the TLS certificates in a way that means that the TLS certificates received when resolving the URL might not be the TLS certificates that you configured.

    If you have an https inspection proxy and it is causing this issue, you must take additional action to ensure these https proxy certificates are trusted and correct.

  • The configuration of your TLS protocols and ciphers do not allow the https requests from your web server to negotiate an allowed TLS protocol and cipher with the IIS web server.

• The IIS bindings for the website are preventing some network adapters from reaching IIS.

  To check if this is the issue, attempt to resolve the server name URL with user accounts on the same machine, and other machines. If some accounts and machines are able to resolve the URL but others cannot, this the cause of the issue is likely to be the IIS site bindings of the website.

  To see the site bindings:

  1. In IIS, click the Default Web Site.

  2. Under Actions, click Bindings.

  3. Review the IP Address settings of the https bindings.

  In mixed IPv4 and IPv6 environments, if an IPv4 address is selected, but IPv6 is used for the connection, or if an IPv6 address is selected, but IPv4 is used for the connection, this can prevent https calls from succeeding.

  Issues with IIS bindings may prevent users from reaching rest.core. If this occurs, the MyID Operator Client displays the error OC10003.

  To prevent IP address issues with IIS bindings, edit the binding of type https to set the IP Address to All Unassigned.

If you do get valid JSON as a response, the web service user on the web server can resolve the server URL. Your issue is therefore probably within your rest.core configuration. A possible cause is:

• The rest.core call is using http.

  OAuth2 requires https, so the rest.core and web.oauth2 web services are configured at installation to require https. In your rest.core configuration file, ensure that MyID:Auth:AuthServerUrl is set to an https address, not an http address. For information on the rest.core configuration file, see section 19.4.1, The rest.core web service configuration file.